-
Notifications
You must be signed in to change notification settings - Fork 310
fix(modal): add icon status style #3504
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WalkthroughThe update refines the CSS classes for the mobile status icon in the modal component. It explicitly sets the icon's height and width, and adds conditional color classes based on the status prop, aligning the mobile icon's appearance with the desktop version. No exported or public entity declarations are changed. Changes
Suggested labels
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
packages/vue/src/modal/src/mobile-first.vueOops! Something went wrong! :( ESLint: 8.57.1 ESLint couldn't find the plugin "eslint-plugin-vue". (The package "eslint-plugin-vue" was not found when loaded as a Node module from the directory "".) It's likely that the plugin isn't installed correctly. Try reinstalling by running the following:
The plugin "eslint-plugin-vue" was referenced from the config file in ".eslintrc.js » @antfu/eslint-config » @antfu/eslint-config-vue". If you still can't figure out the problem, please stop by https://eslint.org/chat/help to chat with the team. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/vue/src/modal/src/mobile-first.vue
(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: PR E2E Test (pnpm test:e2e3)
'h-4 w-4 inline-block sm:hidden mr-1.5 fill-current', | ||
type === 'message' ? 'w-5 h-5 self-center shrink-0' : 'h-6 w-auto', | ||
{ 'text-color-success': status === 'success' }, | ||
{ 'text-color-info-secondary': ['info', 'question'].includes(status) }, | ||
{ 'text-color-warning': status === 'warning' }, | ||
{ 'text-color-error': status === 'error' } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Status-matching is case-sensitive → colour classes silently break when status
is upper-case
statusIcon
/ mobileStatusIcon
are resolved with status.toUpperCase()
, but the colour classes still compare against lower-case literals ('success'
, 'warning'
, …).
If the caller passes 'SUCCESS'
or 'Warning'
, the icon shows up, yet the colour class is not applied – an easy-to-miss visual bug.
Refactor once so both the icon mapping and colour classes use the same normalised value; it also removes the duplication between desktop & mobile blocks.
@@
- status,
+ // normalise status once for icon mapping & CSS utility checks
+ status,
+ statusUpper = typeof status === 'string' ? status.toUpperCase() : '',
+ statusLower = typeof status === 'string' ? status.toLowerCase() : '',
@@
- const statusIcon = typeof status === 'string' ? STATUS_MAPPING_COMPINENT[status.toUpperCase()] : status
- const mobileStatusIcon = typeof status === 'string' ? MOBILE_STATUS_MAPPING_COMPINENT[status.toUpperCase()] : status
+ const statusIcon =
+ typeof status === 'string' ? STATUS_MAPPING_COMPINENT[statusUpper] : status
+ const mobileStatusIcon =
+ typeof status === 'string' ? MOBILE_STATUS_MAPPING_COMPINENT[statusUpper] : status
@@
- { 'text-color-success': status === 'success' },
- { 'text-color-info-secondary': ['info', 'question'].includes(status) },
- { 'text-color-warning': status === 'warning' },
- { 'text-color-error': status === 'error' }
+ { 'text-color-success': statusLower === 'success' },
+ { 'text-color-info-secondary': ['info', 'question'].includes(statusLower) },
+ { 'text-color-warning': statusLower === 'warning' },
+ { 'text-color-error': statusLower === 'error' }
This keeps behaviour unchanged for correctly-cased inputs while fixing upper-/mixed-case ones and DRYs up the comparisons.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In packages/vue/src/modal/src/mobile-first.vue around lines 364 to 369, the
status string is compared in a case-sensitive way for applying colour classes,
causing issues when status is upper- or mixed-case. Normalize the status value
to a consistent case (e.g., lowercase) once before these comparisons and use
this normalized value both for icon resolution and colour class conditions. This
will fix the colour class application for all case variations and reduce
duplication between desktop and mobile icon handling.
PR
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information
Summary by CodeRabbit